home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
FishMarket 1.0
/
FishMarket v1.0.iso
/
fishies
/
301-325
/
disk_313
/
uucp
/
uucp1.lzh
/
man
/
Standards
< prev
next >
Wrap
Text File
|
1989-11-03
|
90KB
|
2,381 lines
Standard for Interchange of USENET Messages
Mark R. Horton
1. Introduction Introduction Introduction Introduction
This document defines the standard format for interchange
of Network News articles among USENET sites. It describes
the format for articles themselves, and gives partial
standards for transmission of news. The news transmission
is not entirely standardized in order to give a good deal
of flexibility to the individual hosts to choose
transmission hardware and software, whether to batch news,
and so on.
There are five sections to this document. Section two
section defines the format. Section three defines the
valid control messages. Section four specifies some valid
transmission methods. Section five describes the overall
news propagation algorithm.
2. Article Format Article Format Article Format Article Format
The primary consideration in choosing an article format is
that it fit in with existing tools as well as possible.
Existing tools include both implementations of mail and
news. (The notesfiles system from the University of __________
Illinois is considered a news implementation.) A standard
format for mail messages has existed for many years on the
ARPANET, and this format meets most of the needs of
USENET. Since the ARPANET format is extensible,
extensions to meet the additional needs of USENET are
easily made within the ARPANET standard. Therefore, the
rule is adopted that all USENET news articles must be
formatted as valid ARPANET mail messages, according to the
ARPANET standard RFC 822. This standard is more
restrictive than the ARPANET standard, placing additional
requirements on each article and forbidding use of certain
ARPANET features. However, it should always be possible
to use a tool expecting an ARPANET message to process a
news article. In any situation where this standard
conflicts with the ARPANET standard, RFC 822 should be
considered correct and this standard in error.
An example message is included to illustrate the fields.
- 2 -
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.general
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.UUCP>
Date: Friday, 19-Nov-82 16:14:55 EST
Followup-To: net.news
Expires: Saturday, 1-Jan-83 00:00:00 EST
Date-Received: Friday, 19-Nov-82 16:59:30 EST
Organization: Bell Labs, Murray Hill
The body of the article comes here, after a blank line.
Here is an example of a message in the old format (before
the existence of this standard). It is recommended that
implementations also accept articles in this format to
ease upward conversion.
From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
Newsgroups: net.general
Title: Usenet Etiquette -- Please Read
Article-I.D.: eagle.642
Posted: Fri Nov 19 16:14:55 1982
Received: Fri Nov 19 16:59:30 1982
Expires: Mon Jan 1 00:00:00 1990
The body of the article comes here, after a blank line.
Some news systems transmit news in the ``A'' format, which
looks like this:
Aeagle.642
net.general
cbosgd!mhuxj!mhuxt!eagle!jerry
Fri Nov 19 16:14:55 1982
Usenet Etiquette - Please Read
The body of the article comes here, with no blank line.
An article consists of several header lines, followed by a
blank line, followed by the body of the message. The
header lines consist of a keyword, a colon, a blank, and
some additional information. This is a subset of the
ARPANET standard, simplified to allow simpler software to
handle it. The ``from'' line may optionally include a
full name, in the format above, or use the ARPANET angle
bracket syntax. To keep the implementations simple, other
formats (for example, with part of the machine address
after the close parenthesis) are not allowed. The ARPANET
convention of continuation header lines (beginning with a
- 3 -
blank or tab) is allowed.
Certain headers are required, certain headers are
optional. Any unrecognized headers are allowed, and will
be passed through unchanged. The required headers are
Relay-Version, Posting-Version, From, Date, Newsgroups,
Subject, Message-ID, Path. The optional headers are
Followup-To, Date-Received, Expires, Reply-To, Sender,
References, Control, Distribution, Organization.
2.1 Required Headers Required Headers Required Headers Required Headers
2.1.1 Relay-Version This header line shows the version _____________
of the program responsible for the transmission of this
article over the immediate link, that is, the program that
is relaying the article from the next site. For example,
suppose site A sends an article to site B, and site B
forwards the article to site C. The message being
transmitted from A to B would have a Relay-Version header
identifying the program running on A, and the message
transmitted from B to C would identify the program running
on B. This header can be used to interpret older headers
in an upward compatible way. Relay-Version must always be
the first in a message; thus, all articles meeting this
standard will begin with an upper case ``R''. No other
restrictions are placed on the order of header lines.
The line contains two fields, separated by semicolons.
The fields are the version and the full domain name of the
site. The version should identify the system program used
(e.g., ``B'') as well as a version number and version
date. For example, the header line might contain
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
This header should not be passed on to additional sites.
A relay program, when passing an article on, should
include only its own Relay-Version, not the Relay-Version
of some other site. (For upward compatibility with older
software, if a Relay-Version is found in a header which is
not the first line, it should be assumed to be moved by an
older version of news and deleted.)
2.1.2 Posting-Version This header identifies the _______________
software responsible for entering this message into the
network. It has the same format as Relay-Version. It
will normally identify the same site as the Message-ID,
unless the posting site is serving as a gateway for a
message that already contains a message ID generated by
mail. (While it is permissible for a gateway to use an
externally generated message ID, the message ID should be
- 4 -
checked to ensure it conforms to this standard and to RFC
822.)
2.1.3 From The From line contains the electronic mailing ____
address of the person who sent the message, in the ARPA
internet syntax. It may optionally also contain the full
name of the person, in parentheses, after the electronic
address. The electronic address is the same as the entity
responsible for originating the article, unless the Sender
header is present, in which case the From header might not
be verified. Note that in all site and domain names,
upper and lower case are considered the same, thus
mark@cbosgd.UUCP, mark@cbosgd.uucp, and mark@CBosgD.UUcp
are all equivalent. User names may or may not be case
sensitive, for example, Billy@cbosgd.UUCP might be
different from BillY@cbosgd.UUCP. Programs should avoid
changing the case of electronic addresses when forwarding
news or mail.
RFC 822 specifies that all text in parentheses is to be
interpreted as a comment. It is common in ARPANET mail to
place the full name of the user in a comment at the end of
the From line. This standard specifies a more rigid
syntax. The full name is not considered a comment, but an
optional part of the header line. Either the full name is
omitted, or it appears in parentheses after the electronic
address of the person posting the article, or it appears
before an electronic address enclosed in angle brackets.
Thus, the three permissible forms are:
From: mark@cbosgd.UUCP
From: mark@cbosgd.UUCP (Mark Horton)
From: Mark Horton <mark@cbosgd.UUCP>
Full names may contain any printing ASCII characters from
space through tilde, with the exceptions that they may not
contain parentheses ``('' or ``)'', or angle brackets
``<'' or ``>''. Additional restrictions may be placed on
full names by the mail standard, in particular, the
characters comma ``,'', colon ``:'', and semicolon ``;''
are inadvisable in full names.
2.1.4 Date The Date line (formerly ``Posted'') is the ____
date, in a format that must be acceptable both to the
ARPANET and to the getdate routine, that the article was
originally posted to the network. This date remains
unchanged as the article is propagated throughout the
network. One format that is acceptable to both is
Weekday, DD-Mon-YY HH:MM:SS TIMEZONE
- 5 -
Several examples of valid dates appear in the sample
article above. Note in particular that ctime format:
Wdy Mon DD HH:MM:SS YYYY
is not acceptable because it is not a valid ARPANET date. ___
However, since older software still generates this format,
news implementations are encouraged to accept this format
and translate it into an acceptable format.
The contents of the TIMEZONE field is currently subject to
revision. Eventually, we hope to accept all possible
worldwide time zone abbreviations, including the usual
American zones (PST, PDT, MST, MDT, CST, CDT, EST, EDT),
the other North American zones (Bering through
Newfoundland), European zones, Australian zones, and so
on. Lacking a complete list at present (and unsure if an
unambiguous list exists), authors of software are
encouraged to keep this code flexible, and in particular
not to assume that time zone names are exactly three
letters long. Implementations are free to edit this
field, keeping the time the same, but changing the time
zone (with an appropriate adjustment to the local time
shown) to a known time zone.
2.1.5 Newsgroups The Newsgroups line specifies which __________
newsgroup or newsgroups the article belongs in. Multiple
newsgroups may be specified, separated by a comma.
Newsgroups specified must all be the names of existing
newsgroups, as no new newsgroups will be created by simply
posting to them.
Wildcards (e.g., the word ``all'') are never allowed in a
Newsgroups line. For example, a newsgroup ``net.all'' is
illegal, although a newsgroup name ``net.sport.football''
is permitted.
If an article is received with a Newsgroups line listing
some valid newsgroups and some invalid newsgroups, a site
should not remove invalid newsgroups from the list.
Instead, the invalid newsgroups should be ignored. For
example, suppose site A subscribes to the classes
``btl.all'' and ``net.all'', and exchanges news articles
with site B, which subscribes to ``net.all'' but not
``btl.all''. Suppose A receives an article with
``Newsgroups: net.micro,btl.general''. This article is
passed on to B because B receives net.micro, but B does
not receive btl.general. A must leave the Newsgroup line
unchanged. If it were to remove ``btl.general'', the
edited header could eventually reenter the ``btl.all''
class, resulting in an article that is not shown to users
- 6 -
subscribing to ``btl.general''. Also, followups from
outside ``btl.all'' would not be shown to such users.
2.1.6 Subject The Subject line (formerly ``Title'') _______
tells what the article is about. It should be suggestive
enough of the contents of the article to enable a reader
to make a decision whether to read the article based on
the subject alone. If the article is submitted in
response to another article (e.g., is a ``followup'') the
default subject should begin with the four characters
``Re: '' and the References line is required. (The user
might wish to edit the subject of the followup, but the
default should begin with ``Re: ''.)
2.1.7 Message-ID The Message-ID line gives the article a __________
unique identifier. The same message ID may not be reused
during the lifetime of any article with the same message
ID. (It is recommended that no message ID be reused for
at least two years.) Message ID's have the syntax
"<" "string not containing blank or >" ">"
In order to conform to RFC 822, the Message-ID must have
the format
"<" "unique" "@" "full domain name" ">"
where ``full domain name'' is the full name of the host at
which the article entered the network, including a domain
that host is in, and unique is any string of printing
ASCII characters, not including "<", ">", or "@". For
example, the "unique" part could be an integer
representing a sequence number for articles submitted to
the network, or a short string derived from the date and
time the article was created. For example, valid message
ID for an article submitted from site ucbvax in domain
Berkeley.ARPA would be "<4123@ucbvax.Berkeley.ARPA>".
Programmers are urged not to make assumptions about the
content of message ID fields from other hosts, but to
treat them as unknown character strings. It is not safe,
for example, to assume that a message ID will be under 14
characters, nor that it is unique in the first 14
characters.
The angle brackets are considered part of the message ID.
Thus, in references to the message ID, such as the
ihave/sendme and cancel control messages, the angle
brackets are included. White space characters (e.g.,
blank and tab) are not allowed in a message ID. All
characters between the angle brackets must be printing
ASCII characters.
- 7 -
2.1.8 Path This line shows the path the article took to ____
reach the current system. When a system forwards the
message, it should add its own name to the list of systems
in the Path line. The names may be separated by any
punctuation character or characters, thus
``cbosgd!mhuxj!mhuxt'', ``cbosgd, mhuxj, mhuxt'', and
``@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp'' and even
``teklabs, zehntel, sri-unix@cca!decvax'' are valid
entries. (The latter path indicates a message that passed
through decvax, cca, sri-unix, zehntel, and teklabs, in
that order.) Additional names should be added from the
left, for example, the most recently added name in the
third example was ``teklabs''. Letters, digits, periods
and hyphens are considered part of site names; other
punctuation, including blanks, are considered separators.
Normally, the rightmost name will be the name of the
originating system. However, it is also permissible to
include an extra entry on the right, which is the name of
the sender. This is for upward compatibility with older
system.
The Path line is not used for replies, and should not be
taken as a mailing address. It is intended to show the
route the message travelled to reach the local site.
There are several uses for this information. One is to
monitor USENET routing for performance reasons. Another
is to establish a path to reach new sites. Perhaps the
most important is to cut down on redundant USENET traffic
by failing to forward a message to a site that is known to
have already received it. In particular, when site A
sends an article to site B, the Path line includes ``A'',
so that site B will not immediately send the article back
to site A. The site name each site uses to identify
itself should be the same as the name by which its
neighbors know it, in order to make this optimization
possible.
A site adds its own name to the front of a path when it
receives a message from another site. Thus, if a message
with path A!X!Y!Z is passed from site A to site B, B will
add its own name to the path when it receives the message
from A, e.g., B!A!X!Y!Z. If B then passes the message on
to C, the message sent to C will contain the path
B!A!X!Y!Z, and when C receives it, C will change it to
C!B!A!X!Y!Z.
Special upward compatibility note: Since the From, Sender,
and Reply-To lines are in internet format, and since many
USENET sites do not yet have mailers capable of
understanding internet format, it would break the reply
- 8 -
capability to completely sever the connection between the
Path header and the reply function. Thus, sites are
required to continue to keep the Path line in a working
reply format as much as possible, until January 1, 1984.
It is recognized that the path is not always a valid reply
string in older implementations, and no requirement to fix
this problem is placed on implementations. However, the
existing convention of placing the site name and an ``!''
at the front of the path, and of starting the path with
the site name, an ``!'', and the user name, should be
maintained at least until 1984.
2.2 Optional Headers Optional Headers Optional Headers Optional Headers
2.2.1 Reply-To This line has the same format as From. ________
If present, mailed replies to the author should be sent to
the name given here. Otherwise, replies are mailed to the
name on the From line. (This does not prevent additional
copies from being sent to recipients named by the replier,
or on To or Cc lines.) The full name may be optionally
given, in parentheses, as in the From line.
2.2.2 Sender This field is present only if the submitter ______
manually enters a From line. It is intended to record the
entity responsible for submitting the article to the
network, and should be verified by the software at the
submitting site.
For example, if John Smith is visiting CCA and wishes to
post an article to the network, using friend Sarah Jones
account, the message might read
From: smith@ucbvax.uucp (John Smith)
Sender: jones@cca.arpa (Sarah Jones)
If a gateway program enters a mail message into the
network at site sri-unix, the lines might read
From: John.Doe@CMU-CS-A.ARPA
Sender: network@sri-unix.ARPA
The primary purpose of this field is to be able to track
down articles to determine how they were entered into the
network. The full name may be optionally given, in
parentheses, as in the From line.
2.2.3 Followup-To This line has the same format as ___________
Newsgroups. If present, follow-up articles are to be
posted to the newsgroup(s) listed here. If this line is
not present, followups are posted to the newsgroup(s)
listed in the Newsgroups line, except that followups to
- 9 -
``net.general'' should instead go to ``net.followup''.
2.2.4 Date-Received This line (formerly ``Received'') is _____________
in a legal USENET date format. It records the date and
time that the article was first received on the local
system. If this line is present in an article being
transmitted from one host to another, the receiving host
should ignore it and replace it with the current date.
Since this field is intended for local use only, no site
is required to support it. However, no site should pass
this field on to another site unchanged.
2.2.5 Expires This line, if present, is in a legal _______
USENET date format. It specifies a suggested expiration
date for the article. If not present, the local default
expiration date is used.
This field is intended to be used to clean up articles
with a limited usefulness, or to keep important articles
around for longer than usual. For example, a message
announcing an upcoming seminar could have an expiration
date the day after the seminar, since the message is not
useful after the seminar is over. Since local sites have
local policies for expiration of news (depending on
available disk space, for instance), users are discouraged
from providing expiration dates for articles unless there
is a natural expiration date associated with the topic.
System software should almost never provide a default
Expires line. Leave it out and allow local policies to be
used unless there is a good reason not to.
2.2.6 References This field lists the message ID's of __________
any articles prompting the submission of this article. It
is required for all follow-up articles, and forbidden when
a new subject is raised. Implementations should provide a
follow-up command, which allows a user to post a follow-up
article. This command should generate a Subject line
which is the same as the original article, except that if
the original subject does not begin with ``Re: '' or ``re:
'', the four characters ``Re: '' are inserted before the
subject. If there is no References line on the original
header, the References line should contain the message ID
of the original article (including the angle brackets).
If the original article does have a References line, the
followup article should have a References line containing
the text of the original References line, a blank, and the
message ID of the original article.
The purpose of the References header is to allow articles
to be grouped into conversations by the user interface
program. This allows conversations within a newsgroup to
- 10 -
be kept together, and potentially users might shut off
entire conversations without unsubscribing to a newsgroup.
User interfaces may not make use of this header, but all
automatically generated followups should generate the
References line for the benefit of systems that do use it,
and manually generated followups (e.g. typed in well after
the original article has been printed by the machine)
should be encouraged to include them as well.
2.2.7 Control If an article contains a Control line, the _______
article is a control message. Control messages are used
for communication among USENET host machines, not to be
read by users. Control messages are distributed by the
same newsgroup mechanism as ordinary messages. The body
of the Control header line is the message to the host.
For upward compatibility, messages that match the
newsgroup pattern ``all.all.ctl'' should also be
interpreted as control messages. If no Control: header is
present on such messages, the subject is used as the
control message. However, messages on newsgroups matching
this pattern do not conform to this standard.
2.2.8 Distribution This line is used to alter the ____________
distribution scope of the message. It has the same format
as the Newsgroups line. User subscriptions are still
controlled by Newsgroups, but the message is sent to all
systems subscribing to the newsgroups on the Distribution
line instead of the Newsgroups line. Thus, a car for sale
in New Jersey might have headers including
Newsgroups: net.auto,net.wanted
Distribution: nj.all
so that it would only go to persons subscribing to
net.auto or net.wanted within New Jersey. The intent of
this header is to further restrict the distribution of a
newsgroup, not to increase it. A local newsgroup, such as
nj.crazy-eddie, will probably not be propagated by sites
outside New Jersey that do not show such a newsgroup as
valid. Wildcards in newsgroup names in the Distribution
line are allowed. Followup articles should default to the
same Distribution line as the original article, but the
user can change it to a more limited one, or escalate the
distribution if it was originally restricted and a more
widely distributed reply is appropriate.
2.2.9 Organization The text of this line is a short ____________
phrase describing the organization to which the sender
belongs, or to which the machine belongs. The intent of
this line is to help identify the person posting the
- 11 -
message, since site names are often cryptic enough to make
it hard to recognize the organization by the electronic
address.
3. Control Messages Control Messages Control Messages Control Messages
This section lists the control messages currently defined.
The body of the Control header is the control message.
Messages are a sequence of zero or more words, separated
by white space (blanks or tabs). The first word is the
name of the control message, remaining words are
parameters to the message. The remainder of the header
and the body of the message are also potential parameters;
for example, the From line might suggest an address to
which a response is to be mailed.
Implementors and administrators may choose to allow
control messages to be automatically carried out, or to
queue them for manual processing. However, manually
processed messages should be dealt with promptly.
3.1 Cancel Cancel Cancel Cancel
cancel <message ID>
If an article with the given message ID is present on the
local system, the article is cancelled. This mechanism
allows a user to cancel an article after the article has
been distributed over the network.
Only the author of the article or the local super user is
allowed to use this message. The verified sender of a
message is the Sender line, or if no Sender line is
present, the From line. The verified sender of the cancel
message must be the same as either the Sender or From
field of the original message. A verified sender in the
cancel message is allowed to match an unverified From in
the original message.
3.2 Ihave/Sendme Ihave/Sendme Ihave/Sendme Ihave/Sendme
ihave <message ID list> <remotesys>
sendme <message ID list> <remotesys>
This message is part of the ``ihave/sendme'' protocol,
which allows one site (say ``A'') to tell another site
(``B'') that a particular message has been received on A.
Suppose that site A receives article ``ucbvax.1234'', and
wishes to transmit the article to site B. A sends the
control message ``ihave ucbvax.1234 A'' to site B (by
- 12 -
posting it to newsgroup ``to.B''). B responds with the
control message ``sendme ucbvax.1234 B'' (on newsgroup
to.A) if it has not already received the article. Upon
receiving the Sendme message, A sends the article to B.
This protocol can be used to cut down on redundant traffic
between sites. It is optional and should be used only if
the particular situation makes it worthwhile. Frequently,
the outcome is that, since most original messages are
short, and since there is a high overhead to start sending
a new message with UUCP, it costs as much to send the
Ihave as it would cost to send the article itself.
One possible solution to this overhead problem is to batch
requests. Several message ID's may be announced or
requested in one message. If no message ID's are listed
in the control message, the body of the message should be
scanned for message ID's, one per line.
3.3 Newgroup Newgroup Newgroup Newgroup
newgroup <groupname>
This control message creates a new newsgroup with the name
given. Since no articles may be posted or forwarded until
a newsgroup is created, this message is required before a
newsgroup can be used. The body of the message is
expected to be a short paragraph describing the intended
use of the newsgroup.
3.4 Rmgroup Rmgroup Rmgroup Rmgroup
rmgroup <groupname>
This message removes a newsgroup with the given name.
Since the newsgroup is removed from every site on the
network, this command should be used carefully by a
responsible administrator.
3.5 Sendsys Sendsys Sendsys Sendsys
sendsys (no arguments)
The ``sys'' file, listing all neighbors and which
newsgroups are sent to each neighbor, will be mailed to
the author of the control message (Reply-to, if present,
otherwise From). This information is considered public
information, and it is a requirement of membership in
USENET that this information be provided on request,
either automatically in response to this control message,
or manually, by mailing the requested information to the
- 13 -
author of the message. This information is used to keep
the map of USENET up to date, and to determine where
netnews is sent.
The format of the file mailed back to the author should be
the same as that of the ``sys'' file. This format has one
line per neighboring site (plus one line for the local
site), containing four colon separated fields. The first
field has the site name of the neighbor, the second field
has a newsgroup pattern describing the newsgroups sent to
the neighbor. The third and fourth fields are not defined
by this standard. A sample response:
From cbosgd!mark Sun Mar 27 20:39:37 1983
Subject: response to your sendsys request
To: mark@cbosgd.UUCP
Responding-System: cbosgd.UUCP
cbosgd:osg,cb,btl,bell,net,fa,to,test
ucbvax:net,fa,to.ucbvax:L:
cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi
3.6 Senduuname Senduuname Senduuname Senduuname
senduuname (no arguments)
The ``uuname'' program is run, and the output is mailed to
the author of the control message (Reply-to, if present,
otherwise From). This program lists all uucp neighbors of
the local site. This information is used to make maps of
the UUCP network. The sys file is not the same as the ___
UUCP L.sys file. The L.sys file should never be _____
transmitted to another party without the consent of the
sites whose passwords are listed therein.
It is optional for a site to provide this information.
Some reply should be made to the author of the control
message, so that a transmission error won't be blamed. It
is also permissible for a site to run the uuname program
(or in some other way determine the uucp neighbors) and
edit the output, either automatically or manually, before
mailing the reply back to the author. The file should
contain one site per line, beginning with the uucp site
name. Additional information may be included, separated
from the site name by a blank or tab. The phone number or
password for the site should NOT be included, as the reply
is considered to be in the public domain. (The uuname
- 14 -
program will send only the site name and not the entire
contents of the L.sys file, thus, phone numbers and
passwords are not transmitted.)
The purpose of this message is to generate and maintain
UUCP mail routing maps. Thus, connections over which mail
can be sent using the site!user syntax should be included,
regardless of whether the link is actually a UUCP link at
the physical level. If a mail router should use it, it
should be included. Since all information sent in
response to this message is optional, sites are free to
edit the list, deleting secret or private links they do
not wish to publicise.
3.7 Version Version Version Version
version (no arguments)
The name and version of the software running on the local
system is to be mailed back to the author of the article
(Reply-to if present, otherwise From).
4. Transmission Methods Transmission Methods Transmission Methods Transmission Methods
USENET is not a physical network, but rather a logical
network resting on top of several existing physical
networks. These networks include, but are not limited to,
UUCP, the ARPANET, an Ethernet, the BLICN network, an NSC
Hyperchannel, and a Berknet. What is important is that
two neighboring systems on USENET have some method to get
a new article, in the format listed here, from one system
to the other, and once on the receiving system, processed
by the netnews software on that system. (On UNIX systems,
this usually means the ``rnews'' program being run with
the article on the standard input.)
It is not a requirement that USENET sites have mail
systems capable of understanding the ARPA Internet mail
syntax, but it is strongly recommended. Since From,
Reply-To, and Sender lines use the Internet syntax,
replies will be difficult or impossible without an
internet mailer. A site without an internet mailer can
attempt to use the Path header line for replies, but this
field is not guaranteed to be a working path for replies.
In any event, any site generating or forwarding news
messages must have an internet address that allows them to
receive mail from sites with internet mailers, and they
must include their internet address on their From line.
- 15 -
4.1 Remote Execution Remote Execution Remote Execution Remote Execution
Some networks permit direct remote command execution. On
these networks, news may be forwarded by spooling the
rnews command with the article on the standard input. For
example, if the remote system is called ``remote'', news
would be sent over a UUCP link with the command ``uux -
remote!rnews'', and on a Berknet, ``net -mremote rnews''.
It is important that the article be sent via a reliable
mechansim, normally involving the possibility of spooling,
rather than direct real-time remote execution. This is
because, if the remote system is down, a direct execution
command will fail, and the article will never be
delivered. If the article is spooled, it will eventually
be delivered when both systems are up.
4.2 Transfer by Mail Transfer by Mail Transfer by Mail Transfer by Mail
On some systems, direct remote spooled execution is not
possible. However, most systems support electronic mail,
and a news article can be sent as mail. One approach is
to send a mail message which is identical to the news
message: the mail headers are the news headers, and the
mail body is the news body. By convention, this mail is
sent to the user ``newsmail'' on the remote machine.
One problem with this method is that it may not be
possible to convince the mail system that the From line of
the message is valid, since the mail message was generated
by a program on a system different from the source of the
news article. Another problem is that error messages
caused by the mail transmission would be sent to the
originator of the news article, who has no control over
news transmission between two cooperating hosts and does
not know who to contact. Transmission error messages
should be directed to a responsible contact person on the
sending machine.
A solution to this problem is to encapsulate the news
article into a mail message, such that the entire article
(headers and body) are part of the body of the mail
message. The convention here is that such mail is sent to
user ``rnews'' on the remote system. A mail message body
is generated by prepending the letter ``N'' to each line
of the news article, and then attaching whatever mail
headers are convenient to generate. The N's are attached
to prevent any special lines in the news article from
interfering with mail transmission, and to prevent any
extra lines inserted by the mailer (headers, blank lines,
etc.) from becoming part of the news article. A program
on the receiving machine receives mail to ``rnews'',
- 16 -
extracting the article itself and invoking the ``rnews''
program. An example in this format might look like this:
Date: Monday, 3-Jan-83 08:33:47 MST
From: news@cbosgd.UUCP
Subject: network news article
To: rnews@npois.UUCP
NRelay-Version: B 2.10 2/13/83 cbosgd.UUCP
NPosting-Version: B 2.9 6/21/82 sask.UUCP
NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
NFrom: derek@sask.UUCP (Derek Andrew)
NNewsgroups: net.test
NSubject: necessary test
NMessage-ID: <176@sask.UUCP>
NDate: Monday, 3-Jan-83 00:59:15 MST
N
NThis really is a test. If anyone out there more than 6
Nhops away would kindly confirm this note I would
Nappreciate it. We suspect that our news postings
Nare not getting out into the world.
N
Using mail solves the spooling problem, since mail must
always be spooled if the destination host is down.
However, it adds more overhead to the transmission process
(to encapsulate and extract the article) and makes it
harder for software to give different priorities to news
and mail.
4.3 Batching Batching Batching Batching
Since news articles are usually short, and since a large
number of messages are often sent between two sites in a
day, it may make sense to batch news articles. Several
articles can be combined into one large article, using
conventions agreed upon in advance by the two sites. One
such batching scheme is described here; its use is still
considered experimental.
News articles are combined into a script, separated by a
header of the form:
##! rnews 1234
where 1234 is the length, in bytes, of the article. Each
such line is followed by an article containing the given
number of bytes. (The newline at the end of each line of
the article is counted as one byte, for purposes of this
count, even if it is stored as CRLF.) For example, a batch
- 17 -
of articles might look like this:
#! rnews 374
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.general
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.UUCP>
Date: Friday, 19-Nov-82 16:14:55 EST
Here is an important message about USENET Etiquette.
#! rnews 378
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.followup
Subject: Notes on Etiquette article
Message-ID: <643@eagle.UUCP>
Date: Friday, 19-Nov-82 17:24:12 EST
There was something I forgot to mention in the last message.
Batched news is recognized because the first character in
the message is ``#''. The message is then passed to the
unbatcher for interpretation.
5. The News Propagation Algorithm The News Propagation Algorithm The News Propagation Algorithm The News Propagation Algorithm
This section describes the overall scheme of USENET and
the algorithm followed by sites in propagating news to the
entire network. Since all sites are affected by
incorrectly formatted articles and by propagation errors,
it is important for the method to be standardized.
USENET is a directed graph. Each node in the graph is a
host computer, each arc in the graph is a transmission
path from one host to another host. Each arc is labelled
with a newsgroup pattern, specifying which newsgroup
classes are forwarded along that link. Most arcs are
bidirectional, that is, if site A sends a class of
newsgroups to site B, then site B usually sends the same
class of newsgroups to site A. This bidirectionality is
not, however, required.
USENET is made up of many subnetworks. Each subnet has a
name, such as ``net'' or ``btl''. The special subnet
``net'' is defined to be USENET, although the union of all
- 18 -
subnets may be a superset of USENET (because of sites that
get local newsgroup classes but do not get net.all). Each
subnet is a connected graph, that is, a path exists from
every node to every other node in the subnet. In
addition, the entire graph is (theoretically) connected.
(In practice, some political considerations have caused
some sites to be unable to post articles reaching the rest
of the network.)
An article is posted on one machine to a list of
newsgroups. That machine accepts it locally, then
forwards it to all its neighbors that are interested in at
least one of the newsgroups of the message. (Site A deems
site B to be ``interested'' in a newsgroup if the
newsgroup matches the pattern on the arc from A to B.
This pattern is stored in a file on the A machine.) The
sites receiving the incoming article examine it to make
sure they really want the article, accept it locally, and
then in turn forward the article to all their interested _____
neighbors. This process continues until the entire
network has seen the article.
An important part of the algorithm is the prevention of
loops. The above process would cause a message to loop
along a cycle forever. In particular, when site A sends
an article to site B, site B will send it back to site A,
which will send it to site B, and so on. One solution to
this is the history mechanism. Each site keeps track of
all articles it has seen (by their message ID) and
whenever an article comes in that it has already seen, the
incoming article is discarded immediately. This solution
is sufficient to prevent loops, but additional
optimizations can be made to avoid sending articles to
sites that will simply throw them away.
One optimization is that an article should never be sent
to a machine listed in the Path line of the header. When
a machine name is in the Path line, the message is known
to have passed through the machine. Another optimization
is that, if the article originated on site A, then site A
has already seen the article. (Origination can be
determined by the Posting-Version line.)
Thus, if an article is posted to newsgroup ``net.misc'',
it will match the pattern ``net.all'' (where ``all'' is a
metasymbol that matches any string), and will be forwarded
to all sites that subscribe to net.all (as determined by
what their neighbors send them). These sites make up the
``net'' subnetwork. An article posted to ``btl.general''
will reach all sites receiving ``btl.all'', but will not
reach sites that do not get ``btl.all''. In effect, the
- 19 -
articles reaches the ``btl'' subnetwork. An article
posted to newsgroups ``net.micro,btl.general'' will reach
all sites subscribing to either of the two classes.
============
From schein Thu Jun 9 14:36:35 1988 remote from cbmvax
Received: by cbmvax.UUCP (1.2/UUCP-Project/Commodore 12/21/87))
id AA14116; Thu, 9 Jun 88 14:36:35 edt
Date: Thu, 9 Jun 88 14:36:35 edt
From: cbmvax!schein (Dan Schein CATS)
Message-Id: <8806091836.AA14116@cbmvax.UUCP>
To: heimat!sysop
Subject: How to UseNet
How to Use USENET Effectively
Matt Bishop
Research Institute for Advanced Computer Science
Mail Stop 230-5
NASA Ames Research Center
Moffett Field, CA 94035
1. Introduction
USENET is a worldwide bulletin board system in which
thousands of computers pass articles back and forth. Of necessi-
ty, customs have sprung up enabling very diverse people and
groups to communicate peaceably and effectively using USENET.
These customs are for the most part written, but are scattered
over several documents that can be difficult to find; in any
case, even if a new user can find all the documents, he most
likely will have neither the time nor the inclination to read
them all. This document is intended to collect all these conven-
tions into one place, thereby making it easy for new users to
learn about the world of USENET. (Old-timers, too, will benefit
from reading this.)
You should read this document and understand it thoroughly
before you even think about posting anything. If you have ques-
tions, please ask your USENET administrator (who can usually be
reached by sending mail to usenet) or a more knowledgeable USENET
user. Believe me, you will save yourself a lot of grief.
The mechanics of posting an article to USENET are explained
in Mark Horton's excellent paper How to Read the Network News; if
you have not read that yet, stop here and do so. A lot of what
follows depends on your knowing (at least vaguely) the mechanics
of posting news.
Before we discuss these customs, we ought to look at the
history of USENET, what it is today, and why we need these con-
ventions.
2. All About USENET
USENET began on a set of computers in North Carolina's
Research Triangle. The programs involved (known as "netnews"
then, and "A news" now) exchanged messages; it was a small,
multi-computer bulletin board system. As time passed, adminis-
trators of other systems began to connect their computers to this
bulletin board system. The network grew. Then, at Berkeley, the
News Version B 2.11 October 19, 1986
news programs were rewritten (this version became known as "B
news") and the format changed to conform to ARPA standards
(again, this became the "B protocol for news".*) This version of
news was very widely distributed, and at this point USENET began
to take on its current shape.
USENET is a logical network (as opposed to a physical net-
work.) It is also a very amorphous network, in that there is no
central administration or controlling site. There is not even an
official list of members, although there is a very complete unof-
ficial one. A site gets access to USENET by finding some other
site already on USENET that it can connect to and exchange news
articles. So long as this second site (called a neighbor of the
first site) remains willing and able to pass articles to and from
the first site, the first site is on USENET. A site leaves the
USENET only when no one is willing or able to pass articles to,
or accept articles from, it.
As a result, USENET has no equivalent of a "sysop" or cen-
tral authority controlling the bulletin board. What little con-
trol is exercised is wielded by the person at each site who is
responsible for maintaining the USENET connections (this person
is called the "USENET administrator.") Because most USENET ad-
ministrators are (relatively) new to USENET, and because adminis-
tering USENET locally involves a great deal of work, most USENET
administrators tend to follow the lead of other, more experi-
enced, administrators (often known somewhat irreverently as "net
gurus.") This is not an abdication of responsibility, but a means
of keeping the amount of work little enough so it can be done
without interfering with the local USENET administrator's job.
An example of this is the list of currently active newsgroups
circulated every month or so. It is not "official" - no one has
that authority - but as the maintainer is doing the work that
every other USENET administrator would have to do otherwise, it
is accepted as a valid list. If the maintainer changes the list
in a way another USENET administrator finds unacceptable, that
administrator can simply ignore the list. (Incidentally, the
"net gurus" became known as such because of the work they have
contributed to USENET. Their experience is a valuable resource
for each USENET administrator.)
Because the USENET has grown so wildly, a number of problems
have appeared. One of these problems is technical, and a number
of the conventions this document describes spring from attempts
to keep this problem under control.
The technical problem arises due to the transport mechanism
used by most USENET sites. Most computers on USENET do not have
access to large-area networks like ARPANET. As a result the only
__________
* See Standard for Interchange of USENET Messages for a
description of the two formats.
News Version B 2.11 October 19, 1986
viable transport mechanism these sites can use is a set of pro-
grams collectively known as UUCP and which communicate over dial-
up telephone lines. Initially, news programs generated one UUCP
command per article. With the explosion of the USENET, the
number of articles simply swamped many sites; phone lines would
be tied up all day transmitting news, and many articles would be
processed at the same time, slowing down the computers notice-
ably.
The solution was to batch messages. This way, many articles
are sent via UUCP with one command, and the command on the re-
ceiving machine would split the file into separate articles,
which could then be processed individually. While this increased
the size of the files being sent, it cut down on the number of
UUCP commands sent, and since sending a command involves quite a
bit of overhead, this decreased the duration of phone calls, and
to a lesser degree the load on the computer. At some sites, such
as Purdue, this was not quite enough, so a simple spooler was im-
plemented to process the individual articles one at a time. This
reduced the system load to a very acceptable amount.
However, the problem has not gone away by any means. In one
sense it has become worse; as more articles are posted to the
network, phone costs and system loads averages increase, and sys-
tem administrators require USENET administrators to cut back or
eliminate newsgroups and to transmit news only at night (which
means long propagation delays). In short, everyone who has any-
thing to do with administering any USENET site is very concerned
about the future of USENET, both in general and at his own site.
Many of the rules you will read address this concern. The
fear that USENET may collapse is not a bogeyman, but very real.
We hope it will not collapse, and the rules below outline some
ways to prevent problems and increase the likelihood that enough
sites will remain on USENET to keep it alive. There is no cen-
tral authority that can force you to follow them, but by doing so
you will help keep USENET a valuable resource to the computer
community.
3. Deciding to Post
Before you decide to post an article, you should consider a
few things.
3.1. Do not repeat postings
This applies even if you did not post the information the
first time around. If you know the answer to a question someone
asked, first read the follow-ups, and if you have something more
to contribute, mail it to the questioner; if you think it should
be seen by others, ask the questioner to summarize the answers he
receives in a subsequent article. One of the biggest problems on
USENET is that many copies of the same answer to a simple ques-
tion are posted.
News Version B 2.11 October 19, 1986
If you want to repost something because you believe it did
not get to other USENET sites due to transmission problems (this
happens sometimes, but a lot less often than commonly believed),
do some checking before you repost. If you have a friend at
another USENET site, call him and ask if the article made it to
his site. Ask your USENET administrator if he knows of any prob-
lems in the USENET; there are special newsgroups to which USENET
administrators subscribe in which problems are reported, or he
can contact his counterparts at other sites for information. Fi-
nally, if you decide you must repost it, indicate in the article
subject that it is a reposting, and say why you are reposting it
(if you don't, you'll undoubtedly get some very nasty mail.)
Reposting announcements of products or services is flatly
forbidden. Doing so may convince other sites to turn off your
USENET access.
When school starts, hoards of new users descend upon the
USENET asking questions. Many of these questions have been
asked, and answered, literally thousands of times since USENET
began. The most common of these questions, and their answers,
have been collected in the hope that the new users will read them
and not re-post the same questions. So, if you want to ask a
question, check Appendix A (Answers to Frequently Asked Ques-
tions) to be sure it isn't one that has been asked and answered
literally hundreds of times before you started reading the
USENET.
3.2. Do not post anything when upset, angry, or intoxicated
Posting an article is a lot like driving a car - you have to
be in control of yourself. Postings which begin "Jane, you ig-
norant slut, ..." are very definitely considered in poor taste*.
Unfortunately, they are also far too common.
The psychology of this is interesting. One popular belief
is that since we interact with USENET via computers, we all often
forget that a computer did not do the posting; a human did. A
contributing factor is that you don't have to look the target of
abuse in the eye when you post an abusive message; eye-to-eye
contact has an amazing effect on inhibiting obnoxious behavior.
As a result, discussions on the USENET often degenerate into a
catfight far more readily than would a face-to-face discussion.
Before you post an article, think a minute; decide whether
or not you are upset, angry, or high. If you are, wait until you
calm down (or come down) before deciding to post something. Then
think about whether or not you really want to post it. You will
be amazed what waiting a day or even a few hours can do for your
perspective.
__________
* Unless you are critiquing Saturday Night Live.
News Version B 2.11 October 19, 1986
Bear in mind that shouting hasn't convinced anyone of any-
thing since the days of Charlemagne, and being abusive makes peo-
ple hold even more tenaciously to their ideas or opinions. Gen-
tleness, courtesy, and eloquence are far more persuasive; not
only do they indicate you have enough confidence in your words to
allow them to speak for you, but also they indicate a respect for
your audience. This in turn makes it easier for your audience to
like or respect you - and people tend to be far more interested
in, and receptive to, arguments advanced by those they like or
respect than by writers who are abusive. Finally, remember that
some discussions or situations simply cannot be resolved. Be-
cause people are different, agreed-upon facts often lead to wild-
ly different feelings and conclusions. These differences are
what makes life so wonderful; were we all alike, the world would
be a very boring place. So, don't get frantic; relax and enjoy
the discussion. Who knows, you might even learn something!
3.3. Be sure your posting is appropriate to USENET
Some things are inappropriate to post to USENET. Discussing
whether or not some other discussion is appropriate, or if it is
in the right newsgroup, is an example. Invariably, the "meta-
discussion" generates so many articles that the discussion is
simply overwhelmed and vanishes; but the meta-discussion lingers
on for several weeks, driving most of the readers of that news-
group out of their collective minds. Help preserve the sanity of
your fellow USENET readers by mailing such comments to the people
involved, rather than posting them.
Another example of inappropriate postings is the infamous
"spelling flame." Every few months someone takes another poster
to task for poor spelling or grammar. Soon, everyone jumps on
the bandwagon, tearing apart one another's postings for such er-
rors. To put it mildly, this angers almost everyone involved for
no real reason. Please remember that we all make mistakes, and
there are a lot of people for whom English is a second language.
So, try to keep your spelling and grammar comments to yourself -
but if you find you simply cannot, mail them to the poster rather
than posting them.
Far more insidious are requests similar to "How can I splice
into the local cable TV transmission line?" Posting to USENET is
akin to publishing, so don't ask for or post instructions on how
to do something illegal. And please don't quote the First Amend-
ment, or the laws allowing freedom of speech in your country;
while the posting programs will not stop you, the aftermath could
be very unpleasant - lawsuits and court trials usually are, and
the USENET would certainly collapse as sites dropped from it to
protect themselves from legal liability. You wouldn't want that
on your conscience, would you? Of course not.
Related to this is the next rule.
News Version B 2.11 October 19, 1986
3.4. Do not post other people's work without permission
Posting something to USENET puts it in the public domain for
all practical purposes. So, be careful about posting things like
UNIX*-related material (specifically source code) or company do-
cuments; consider licensing and nondisclosure agreements first.
Some people regard the posting of "diffs" based on licensed code
to be a suitable compromise, as they are only useful to those who
have the base code already.
Copyrighted works are a separate problem. Both United
States and international law provide protection for copyrighted
works; other than short extracts for purposes of criticism, you
cannot copy a copyrighted work in whole or in part without per-
mission of the copyright holder (who may, or may not, be the au-
thor.) Without this protection, artists could not make any money
and hence would have limited incentive to make the fruits of
their art available at all. Posting a copyrighted work without
permission is theft, even though the property stolen is not tan-
gible in most cases. Hence, posting movie and book reviews, song
lyrics, or anything else which is copyrighted without the permis-
sion of the copyright holder, could cause you personally, your
company, or the USENET itself to be held liable for damages.
Please be very careful that you obey the law when posting such
material!
3.5. Don't forget that opinions are those of the poster and not
his employer.
Every so often, someone will post a particularly disgusting
article, and a number of responses will ask if all employees of
the original poster's company share his (revolting) opinion, or
suggest that action be taken against that company. Please
remember that all opinions or statements in articles are to be
attributed to the poster only, and in particular, do not neces-
sarily represent the opinions of the poster's employer, the owner
of the computer on which the article originated, or anyone in-
volved with any aspect of USENET - and consequently the responsi-
bility for any USENET message rests with the poster and with no
one else. The appropriate response is not to attack the company
or its other employees; let the poster know what you think of his
posting via mail. If the postings continue, take advantage of
the news software's presenting you with the author's name and the
subject line and then asking if you want to see the article;
start looking for the poster's name or the offensive subject in
the articles presented to you and skip them. If you really get
offended, you can unsubscribe from a newsgroup.
Part of the price of freedom is allowing others to make
fools of themselves. You wouldn't like to be censored, so don't
advocate censorship of others. No one is forcing you to read the
__________
*UNIX is a registered trademark of AT&T.
News Version B 2.11 October 19, 1986
postings.
In some countries, posting or receiving certain types of ar-
ticles may be a criminal offense. As a result, certain news-
groups which circulate freely within the United States may not be
circulated in other nations without risking civil or criminal li-
abilities. In this case, the appropriate action for sites in
that country is neither to accept nor to transmit the newsgroup.
No site is ever forced to accept or pass on any newsgroup.
4. Where to Post
The various newsgroups and distributions have various rules
associated with their use. This section will describe these
rules and offer suggestions on which newsgroups to post your mes-
sage.
4.1. Keep the distribution as limited as possible
A basic principle of posting is to keep the distribution of
your article as limited as possible. Like our modern society,
USENET is suffering from both an information glut and information
pollution. It is widely believed that the USENET will cease to
function unless we are able to cut down the quantity of articles.
One step in this direction is not to post something to places
where it will be worthless. For example, if you live in Hacken-
sack, New Jersey, the probability of anyone in Korea wanting to
buy your 1972 Toyota is about as close to zero as you can get.
So confine your posting to the New Jersey area.
To do this, you can either post to a local group, or post to
a net-wide group and use the distribution feature to limit how
widely your article will go. When you give your posting program
(usually postnews(1)) a distribution, you are (in essence) saying
that machines which do not recognize that distribution should not
get the article. (Think of it as a subgroup based on locality
and you'll get the idea.) For example, if you are posting in the
San Francisco Bay Area, and you post your article to rec.auto but
give ba as the distribution, the article will not be sent beyond
the San Francisco Bay Area (to which the ba distribution is lo-
cal) even though you put it in a net-wide newsgroup. Had you
given the distribution as ca (the California distribution), your
article would have been sent to all Californian sites on USENET.
Had you given the distribution as world, your article would have
been sent to all sites on USENET.
4.2. Do not post the same article twice to different groups
If you have an article that you want to post to more than
one group, post to both at the same time. Newer versions of the
news software will show an article only once regardless of how
many newsgroups it appears in. But if you post it once to each
different group, all versions of news software will show it once
for each newsgroup. This angers a lot of people and wastes
News Version B 2.11 October 19, 1986
everybody's time.
4.3. Do not post to moderated newsgroups.
You may not post directly to certain newsgroups; you cannot
post to some at all. Newer versions of the news software will
inform you when either of these restrictions apply, but older
versions of news software will not.
If you want to have the appropriate moderator post some-
thing, mail it to the moderator. (If you do not know the ad-
dress, ask your USENET administrator. In some cases, the
software will automatically mail, rather than post, your article
to the moderator.)
4.4. Ask someone if you can't figure out where to post your ar-
ticle
If you cannot figure out where to post something, look in
news.announce.newusers for the list of active newsgroups. (This
is posted biweekly. If you can't find it, look at the list in
How to Read the Network News; but be aware that list is undoubt-
edly out of date already.) If your article does not seem to fit
in any of the listed groups, post it to misc.misc or don't post
it.
If you still are not sure which newsgroup to post your arti-
cle to, ask an old-timer. If your site doesn't have any old-
timers (or none of the old-timers will admit to being old-
timers), contact any of the following people:
Gene Spafford (spaf@gatech.CSNET, spaf@gatech.UUCP)
Mark Horton (mark@cbosgd.UUCP)
Rick Adams (rick@seismo.CSS.GOV, rick@seismo.UUCP)
Chuq Von Rospach (chuq@sun.UUCP)
Matt Bishop (mab@riacs.ARPA, mab@riacs.UUCP)
We will be happy to help you. But, please, do not post the arti-
cle to the net before you ask us!
4.5. Be sure there is a consensus before creating a new news-
group
Creating a new newsgroup is, in general, a very bad idea.
Currently, there are so many articles being posted that the
USENET is in danger of collapse as site after site decides to
cease to accept and retransmit certain newsgroups. Moreover,
there is no established procedure for deleting a newsgroup, so
once created, newsgroups tend to stay around. They also tend to
encourage people to think up new newsgroups, and the cycle re-
peats. Try to avoid thinking up new newsgroups.
If, however, you believe a new group should be created, be
sure you have a consensus that the group is needed (either a
News Version B 2.11 October 19, 1986
mailing list has enough traffic and readers to justify turning it
into a newsgroup, or a discussion in a current newsgroup becomes
so large for a period of time long enough to warrant splitting it
into a newsgroup.) Then post an article to news.group as well as
any other groups related to your proposed new group, and discuss
the topics you are proposing be covered in your new group, what
it should be called, whether it is really needed, and so forth.
Try to resolve all objections, and take into account all sugges-
tions and comments; finally, have everyone mail you a "yes" or
"no" vote on whether the group should be created. Try to get at
least 40 or 50 "yes" votes before creating the group; if you want
to be safe, get around 100.
4.6. Watch out for newsgroups which have special rules about
posting
Some newsgroups have special rules. This section summarizes
them.
rec.arts.books Do not post anything revealing a plot or a
plot twist without putting the word "spoiler"
somewhere in the "Subject" field. This will
let those who do not wish to have a surprise
spoiled skip the article.
rec.humor If you want to post an offensive joke (this
includes racial, religious, sexual, and sca-
tological humor, among other kinds) rotate
it. (If you do not know what this means,
look in the section Writing Your Posting.)
rec.arts.movies Do not post anything revealing a plot or a
plot twist without putting the word "spoiler"
in the "Subject" field. This will let those
who do not wish to have a surprise spoiled
skip the article.
news.group Discussions about whether or not to create
new groups, and what to name them, go here.
Please mail your votes to the proposer; don't
post them.
comp.sources Source code postings go here. Discussions
are not allowed. Do not post bug fixes here.
comp.sources.bugs Bug reports and bug fixes to sources posted
in comp.sources go here.
comp.sources.wanted Requests for sources go here.
misc.test Use the smallest distribution possible. In
the body of the message, say what you are
testing.
News Version B 2.11 October 19, 1986
misc.wanted Requests for things other than source code go
here. Please use the smallest distribution
possible. Post offers here, too.
5. Writing the Article
Here are some suggestions to help you communicate effective-
ly with others on the USENET. Perhaps the best advice is not to
be afraid to consult a book on writing style; two of the best are
How to Write for the World of Work by Cunningham and Pearsall,
and Elements of Style by Strunk and White.
5.1. Write for your audience
USENET is an international network, and any article you post
will be very widely read. Even more importantly, your future em-
ployers may be among the readers! So, try to make a good impres-
sion.
A basic principle of all writing is to write at your
readers' reading level. It is better to go below than above.
Aiming where "their heads ought to be" may be fine if you are a
college professor (and a lot of us would dispute even that), but
it is guaranteed to cause people to ignore your article. Studies
have shown that the average American reads at the fifth grade
level and the average professional reads at the twelfth grade
level.
5.2. Be clear and concise
Remember that you are writing for a very busy audience; your
readers will not puzzle over your article. So be very clear and
very concise. Be precise as well; choose the least ambiguous
word you can, taking into account the context in which you are
using the word. Split your posting into sections and paragraphs
as appropriate. Use a descriptive title in the "Subject" field,
and be sure that the title is related to the body of the article.
If the title is not related, feel free to change it to a title
that is.
5.3. Proofread your article
This is a matter of courtesy; since you want others to read
your article, the least you can do is check that it says what you
mean in a clear, concise manner. Check for typographical errors,
silly grammar errors, and misspellings; if you have a spelling
checking program, use it. Also be sure the article is easy to
read. Use white space - blanks, tabs, and newlines - and both
upper and lower case letters. Do not omit the definite and inde-
finite articles, either; not only do "a", "an", and "the" make a
posting much easier to read, their omission can make a posting
ambiguous.
News Version B 2.11 October 19, 1986
5.4. Be extra careful with announcements of products or services
When writing a product or service announcement, bear in mind
that others will be paying most of the telephone bills. So, if
you are announcing several things, combine all the announcements
into one article. Mark the posting as a product or service an-
nouncement in the title in the "Subject" field. Advertising hy-
perbole is not appropriate here; remember that your audience is
to a large degree technically literate, and your product will
stand or fall on its technical merits. Be aware that posting ob-
noxious or inappropriate advertisements is very serious and if
you do it, you may find your neighbors yanking your USENET ac-
cess.
5.5. Indicate sarcasm and humor
Remember that people cannot see you when they read your
posting; hence, all the subtle nuances of body and facial motion
are hidden. It can be quite difficult to tell when you are being
sarcastic or humorous. To deal with this problem, the USENET
readers and posters have developed a special sign. Mark passages
you intend to be taken as humorous with the "smiley face", while
looks like this: ":-)". (Think of a head facing you lying on its
right side and look again if you don't understand why that symbol
was chosen.) As for sarcasm, there is no universal symbol for
that (unless the sarcasm is meant humorously, in which case use
the smiley face again.) But mark your passage so everyone will
realize you are being sarcastic.
5.6. Mark postings which spoil surprises
High on the list of obnoxious messages are those that spoil
the plot of a book or movie by giving away an unexpected detail.
If you post such an article, please put the word "spoiler" in the
"Subject" field of your posting, so people who do not wish to
have a surprise ruined can skip the article.
5.7. Rotate offensive postings
If you feel you must post a message that may offend people,
you can take steps to be sure the message will only be read by
those who explicitly ask for it to be shown to them. The USENET
convention is to encrypt these messages by shifting each letter
13 characters, so that (for example) "a" becomes "n". (In more
precise terms, this is a Caesar cipher of shift 13; on the
USENET, it is called rot13.) When you do this, put the word
"rot13" in the "Subject" field. The news reader you are using
almost certainly has a command to encrypt and decrypt such mes-
sages; if not, use the UNIX command
tr a-zA-Z n-za-mN-ZA-M
News Version B 2.11 October 19, 1986
5.8. The shorter your signature, the better
Keep signatures concise; 2 or 3 lines are usually plenty.
Include your name and addresses on any major networks (such as
ARPANET, BITNET, or CSNET). This helps people contact you quick-
ly and easily, usually more so than by following the return path
of the article. Do not include pictures, graphics or clever quo-
tations that make the signature longer; this is not the appropri-
ate place for them, and many sites resent paying the phone bills
for such signatures.
6. Conclusion and Summary
Here is a list of the rules given above:
=> Deciding to post
+ Do not repeat postings
+ Do not post anything when upset, angry, or intoxicat-
ed
+ Be sure your posting is appropriate to USENET
+ Do not post other people's work without permission
+ Don't forget that opinions are those of the poster
and not his company
=> Where to Post
+ Keep the distribution as limited as possible
+ Do not post the same article twice to different
groups
+ Do not post to news.announce newsgroups
+ Ask someone if you can't figure out where to post
your article
+ Be sure there is a consensus before creating a new
newsgroup
+ Watch out for newsgroups which have special rules
about posting
=> Writing the Article
+ Write for your audience
+ Be clear and concise
News Version B 2.11 October 19, 1986
+ Proofread your article
+ Be extra careful with announcements of products or
services
+ Indicate sarcasm and humor
+ Mark postings which spoil surprises
+ Rotate offensive postings
+ The shorter your signature, the better
The USENET can be a great place for us all. Sadly, not
enough people are following the customs that have been esta-
blished to keep the USENET civilized. This document was written
to educate all users of the USENET on their responsibilities.
Let's clean up the USENET, and turn it into a friendly, helpful
community again!
Acknowledgements: The writing of this document was inspired by
Chuq von Rospach's posting on USENET etiquette, and it draws on
previous work by Mark Horton, A. Jeff Offutt, Gene Spafford, and
Chuq von Rospach.
News Version B 2.11 October 19, 1986
Appendix A. Answers to Frequently Asked Questions
originally from Jerry Schwarz (jerry@eagle.UUCP)
modified by Gene Spafford (spaf@gatech.UUCP)
modified by Matt Bishop (mab@riacs.ARPA)
This document discusses some items that occur repeatedly on
USENET. They frequently are submitted by new users, and result
in many follow-ups, sometimes swamping groups for weeks. The
purpose of this note is to head off these annoying events by
answering some questions and warning about the inevitable conse-
quence of asking others. If you don't like my answers, let me
know and I may include revisions in future versions of this note.
1. What does UNIX stand for?
It is not an acronym, but is a pun on "MULTICS." MULTICS is a
large operating system that was being developed shortly be-
fore UNIX was created.
2. What is the derivation of "foo" as a filler word?
The favorite story is that it comes from "fubar" which is an
acronym for "fouled up beyond all recognition," which is sup-
posed to be a military term. (Various forms of this exist,
"fouled" usually being replaced by a stronger word.) "Foo"
and "Bar" have the same derivation.
3. Is a machine at "foo" on the net?
These questions belong in news.config if anywhere, but in
fact your best bet is usually to phone somebody at "foo" to
find out. If you don't know anybody at "foo" you can always
try calling and asking for the "computer center." Also, see
the newsgroup mod.map, where maps of USENET and the UUCP net-
work are posted regularly.
4. What does "rc" at the end of files like .newsrc mean?
According to Dennis Ritchie, "The name rc comes from RUNCOM,
which was the rough equivalent on the MIT CTSS system of what
UNIX calls shell scripts. Of course, RUNCOM derives from run
commands."
5. What do "- (nf)" and "Orphaned Response" in an item's title
mean?
It means that the item was created by "notefiles," an alter-
native news handling interface that many people prefer. If
you want to find out more you can read the Notesfile System
Reference Manual" or contact uiucdcs!essick.
News Version B 2.11 October 19, 1986
6. What does ":-)" mean?
This is the net convention for a "smiley face." It means that
something is being said in jest. If it doesn't look like a
smiley face to you, flop your head over to the left and look
again.
7. How do I decrypt jokes in rec.humor?
The standard cipher used in rec.humor in called "rot13." Each
letter is replaced by the letter 13 further along in the al-
phabet (cycling around at the end). Most systems have a
built in command to decrypt such articles; readnews(1) and
vnews(1) have the D command, rn(1) (another popular public-
domain full screen news reader) has the X or <CONTROL-X> com-
mands, notes(1) has % or R. If your system doesn't have a
program to encrypt and decrypt these, you can quickly create
a shell script using tr(1):
tr A-Za-z N-ZA-Mn-za-m
On some versions of UNIX, the tr command should be written
as:
tr "[a-m][n-z][A-M][N-Z]" "[n-z][a-m][N-Z][A-M]"
8. soc.net-people: Is John Doe out there anywhere?
I suspect that these items are people looking for freshman
roommates that they haven't seen in ten years. If you have
some idea where the person is you are usually better off cal-
ling the organization. For example, if you call any Bell
Labs location and request John Doe's number. They can give
it to you even if he works at a different location.
9. sci.math: Proofs that 1 = 0.
Almost everyone has seen one or more of these in high school.
They are almost always based on either division by 0 or tak-
ing the square root of a negative number.
10. rec.games: Where can I get the source for empire(6) or ro-
gue(6)?
You can't. The authors of these games, as is their right,
have chosen not to make the sources available.
11. comp.unix.wizards: How do I remove files with non-ASCII char-
acters in their names?
You can try to find a pattern that uniquely identifies the
file. This sometimes fails because a peculiarity of some
shells is that they strip off the high-order bit of charac-
ters in command lines. Next, you can try an "rm -i", or "rm
News Version B 2.11 October 19, 1986
-r" (see rm(1).) Finally, you can mess around with i-node
numbers and find(1).
12. comp.unix.wizards: There is a bug in the way UNIX handles
protection for programs that run setuid.
There are indeed problems with the treatment of protection in
setuid programs. When this is brought up, suggestions for
changes range from implementing a full capability list ar-
rangement to new kernel calls for allowing more control over
when the effective id is used and when the real id is used to
control accesses. Sooner or later you can expect this to be
improved. For now you just have to live with it.
13. soc.women: What do you think about abortion?
Although abortion might appear to be an appropriate topic for
soc.women, more heat than light is generated when it is
brought up. Since the newsgroup talk.abortion has been
created, all abortion-related discussion should take place
there.
14. soc.singles: What do "MOTOS," "MOTSS,", "MOTAS", and "SO"
stand for?
Member of the opposite sex, member of the same sex, member of
the appropriate sex, and significant other, respectively.
15. How do I use the "Distribution" feature?
When postnews(1) prompts you for a distribution, it's asking
how widely distributed you want your article. The set of
possible replies is different, depending on where you are,
but at Bell Labs in Murray Hill, New Jersey, possibilities
include:
local local to this machine
mh Bell Labs, Murray Hill Branch
nj all sites in New Jersey
btl All Bell Labs machines
att All AT&T machines
usa Everywhere in the USA
na Everywhere in North America
world Everywhere on USENET in the world
If you hit <RETURN>, you'll get the default, which is the
first part of the newsgroup name. This default is often not
appropriate - please take a moment to think about how far
away people are likely to be interested in what you have to
say. Used car ads, housing wanted ads, and things for sale
other than specialized equipment like computers certainly
shouldn't be distributed to Europe and Korea, or even to the
next state.
News Version B 2.11 October 19, 1986
The newsgroup misc.forsale exists for postings of sale an-
nouncements. Its distribution is limited to North America;
posters should restrict this distribution even further, if
possible and appropriate.
16. Why do some people put funny lines ("bug killers") at the be-
ginning of their articles?
Some earlier versions of news had a bug which would drop the
first 512 or 1024 bytes of text of certain articles. The bug
was triggered whenever the article started with white space
(a blank or a tab). A fix many people adopted was to begin
their articles with a line containing a character other than
white space. This gradually evolved into the habit of in-
cluding amusing first lines.
The original bug has since been fixed in newer version of
news, and sites running older versions of news have applied a
patch to prevent articles from losing text. The "bug-killer"
lines are therefore probably no longer needed, but they
linger on.
17. What is the address or phone number of the "foo" company?
Try the white and yellow pages of your phone directory,
first; a sales representative will surely know, and if you're
a potential customer they will be who you're looking for.
Phone books for other cities are usually available in li-
braries of any size. Whoever buys or recommends things for
your company will probably have some buyer's guides or na-
tional company directories. Call or visit the reference desk
of your library; they have several company and organization
directories and many will answer questions like this over the
phone. Remember if you only know the city where the company
is, you can telephone to find out their full address or a
dealer. The network is not a free resource, although it may
look like that to some people. It is far better to spend a
few minutes of your own time researching an answer rather
than broadcast your laziness and/or ineptness to the net.
News Version B 2.11 October 19, 1986